The invention relates to the sending of unscheduled messages in response to a network event.
The majority of communication devices are primarily intended to communicate data whilst they are being operated by a nearby user. For example, a typical telephone or personal computer is designed to allow a user who is holding, or is at least near to, the device to speak or type data into the device and to communicate that data to a user at another location. However, it is anticipated that there will be an increase in the number of devices that communicate automatically without a user being in attendance. For example, it has been forecast that in the future devices such as domestic appliances, motor vehicles and utility meters will commonly be capable of sending data to report on their operational state and receiving data such as upgraded operating software.
A communication network for machine-to-machine (M2M) communications may comprise a base station and one or more terminals with which the base station is required to communicate. The base station suitably shares the available communication resource between the terminals (which may number several thousand if the geographical area covered by the base station is large).
The protocol for the wireless link between the base stations and the terminals is suitably one that is optimized for M2M communication. Preferably the protocol also operates in so-called whitespace: a part of the spectrum that is made available for unlicensed or opportunistic access. Conveniently, that may be in the UHF TV band which spans all or part of the range from 450 MHz to 800 MHz, depending on the country. A large amount of spectrum has been made available for unlicensed wireless systems in this frequency range. A problem with operating in whitespace is that the available bandwidth is variable and cannot be guaranteed. These limitations are well-matched to the capabilities of M2M in which there is no human interaction. M2M networks are typically tolerant of delays, dropped connections and high latency communications.
In an M2M network the vast majority of the traffic is scheduled. This scheduled traffic may include periodic meter readings, sensor updates, signal readings etc. However, terminals may also be programmed to send unscheduled alerts under certain conditions, such as a power failure. The terminals may treat the alert messages as messages that should be transmitted as soon as possible. The network may be designed to make provision for the terminals to schedule this type of message by allocating a part of every frame to contended access transmissions. However, some of the alert conditions may be geographically widespread, with the result that a large number of contended access “alert” messages may be transmitted. This could be problematic for the network.
A simple solution is to require alert messages to have a large “back-off”. Under this arrangement the terminal generates a random delay for any alert, and waits the duration of that random delay before transmitting its alert message. If the range of the potential delays is sufficiently large then the contended access messages from a large number of terminals will be sufficiently spread out in time to avoid network congestion. However, this approach will inherently result in some long delays in receiving alert messages which may not be acceptable to the operators of the terminals. For example, owners of electricity networks may wish to know within a few seconds whether there has been a power failure. Furthermore, even if it is successful in spreading the load, this arrangement may still result in a large quantity of unnecessary network traffic.
Another example of an event that can trigger a flood of unscheduled messages is the transmission of broadcast data by a base station. Broadcast data is sent to multiple terminals. Often, some of those terminals will require all or part of the data to be retransmitted because they did not receive all of it successfully. One option would be to simply retransmit the data a fixed number of times in the hope that all of the terminals receive it. However, this is not reliable. There may be instances when a fixed number of retransmissions is still not sufficient for all of the terminals to have received all of the data. This option may also be inefficient, as it involves retransmitting all of the data when at least some of the data may have been received successfully by all of the terminals. A further option would be for the base station to check with each individual terminal whether it needs any parts of the data to be retransmitted. This can take a long time, particularly on a busy base station. The preferred option is therefore for the base station to accept contended access messages back to the base station from terminals requesting retransmission of some or all of the broadcast message. In a busy network the base station could be flooded with contended access retransmission requests. If many terminals try to send their retransmission requests at the same time, it is possible that the base station will not receive any of them.
Therefore, there is a need for a mechanism for dealing with the large number of messages that may be triggered by a network event in a communication network.